1. Field of the Invention
This invention relates to enterprise application integration, and more particularly relates to synchronization of business objects between enterprise applications.
2. Description of the Related Art
The business object is a standard form of data storage and transfer in enterprise information systems (EISs) today. The business object structure is defined by a business object definition, and a particular business object with data included is called an instance of the business object. These business object instances are the standard method of transferring information between EISs of different types. Since EISs of different types are likely to have different business object definitions, an application which integrates EISs of different types must transform the business object instance contents between the two EISs to match the business object definitions on each side, and ensure that the same data is properly reflected on each side.
Synchronization is a specific pattern of integrating information between EISs. Synchronization requires that any change in a set of business objects within one EIS be reflected within the equivalent set of business objects within another EIS. This requires more than merely passing business object instances between the two EISs. For example, if the business object instances for a given system represent customer orders, a deletion of a customer order on a first EIS must be reflected as a deletion of the same order on the second EIS. Likewise, removal or changes of information within an order in the first EIS must be reflected as such in the second EIS.
The current method of enacting synchronization is to pass business object instances with instance level annotations. These annotations note that the instance has changed, and what change needs to be enacted in the target EIS. In one example, these annotations are called “verbs.” In another example, these annotations are in data fields accompanying a business object instance, called a change summary. This change information (i.e. “verbs,” “change summary,” and the like) used for synchronizing business object instances is referred to herein as the “change history” to avoid confusion with implementation-specific terms used in the art.
Current synchronizations between EISs require that an integration developer write transformation definitions and rules. These transformation rules and definitions relate specifically to transformations of data object attributes, or “field level” transformations. For example, an attribute “fullname” in a source data object may need to be changed to two attributes, “firstname” and “lastname” in a destination data object.
The protocol and complexity of change history information may require integration software or script developers to write transformations for change history information in order to maintain interoperability as data structures storing change history become more complex. For example, an attribute for a source data object may have a change in the change history with the annotation “update,” while the equivalent annotation in the destination data object might be “delete.” Thus, writing transformation instructions for change histories increases the work load for the integration developer. This problem is exacerbated as the change histories become more complex. Unfortunately, conventional integration servers do not perform automatic transformation of change histories. Currently, the only way to perform change history transformations is for the integration developer to manually write such annotation transformations.
Another problem is that the change history information may not currently be transferred to the destination. For example, a change in a source data object may cause the annotation verb to say update, but then after passing through the integration server, the destination object may have no verb (or at least not an update verb) but instead the changes may have already been made to the fields such that the destination EIS simply copies all fields regardless of whether a particular field has actually changed or not. This adds time and consumes resources to perform unnecessary copies. This transfer of information could be done more efficiently if the change history about specific fields that have changed was communicated to the destination EIS.
From the foregoing discussion, it should be apparent that a need exists for an apparatus, system, and method that automatically detects, preserves, and propagates change histories between EISs. Beneficially, such an apparatus, system, and method would perform these functions for field level moves and copies, as well as child-object level moves and copies.